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I. INTRODUCTION 



A. BACKGROUND 

The motivation for this thesis stems from years of frustration on the part of the 
author to gain an insight into how to "integrate" deployable communications systems. 
Integrate is set off in quotes because the word can mean many things to many people. 
In this context, it will be taken to parallel the ideas from systems theory, which states: 

• The whole is more than the sum of parts, 

• The whole determines the nature of the parts, 

• The parts cannot be understood if considered in isolation from the whole, and 

• The parts are dynamically interrelated and interdependent. [Ref. l:p. 10] 

This means that communications support is more than just a set of wires between 
two points. Integration concepts should encompass not only the technical aspects of 
communications, but also the management and organizational structures which ultimately 
enable the wires to exist 

Pre-thesis research indicated that the above concept was still not very prevalent 
among those who are charged with the responsibility to manage deployable systems. This 
is somewhat understandable given the nature of the task. Communications systems 
themselves are complex. They are the single common denominator throughout a theater; 
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every functional area is affected by communications. This makes the gaining of 
consensus among users challenging due to differing opinions of priorities and 
requirements. Further, while the management mechanism used to eventually field a 
system seems to have structure in theory, the execution is frequently considered 
fragmented in actual operation. 

As such, there are two separate threads that run through this thesis: the fundamental 
issues relating to the physical process of providing communications, and the 
organizational issues which impact the Air Force’s ability to put those physical systems 
in place. They are distinct, yet intertwined, and systems theory maintains both must be 
understood if the "whole" of deployable communications is to be understood. 

B. TERMS 

Many terms have come to be associated with communications over the years. 
Command and control, or C 2 , is frequently joined with communications to form C 3 . 
Later, computers and intelligence were added to C 3 to form C*I. All terms are used in 
this paper primarily due to the thrust of the source documents. While the terms are not 
exactly interchangeable, the frequent use of C 3 and C*I in documents illustrates the 
interdependence of elements. This thesis will consider communications as the bridge 
between where information is processed (computers and intelligence) and where it is used 
to make decisions (command and control). 
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C. SCOPE 



Tackling a project such as this forced the focus to remain at a fairly high level. 
Any single issue could lend itself to in-depth analysis. But the challenge is not one of 
solving individual problems, it is one of integrating all of those solutions into a larger, 
workable whole. In our case, it is the communications supporting the warfighter in a 
deployed environment. To stay manageable, the scope was generally limited to Air Force 
systems, with the understanding that the Air Force systems are themselves part of a 
larger, joint system. 

D. OVERVIEW BY CHAPTER 

Chapter II is a review of three previous studies of deployable communications. The 
objectives, findings, and recommendations of the studies are discussed and summarized. 

Chapter III provides a snapshot of the joint and USAF views of architectures. The 
development flows from high level guidance from the joint staff through to the directives 
which stipulate the Air Force deployable communications architecture. 

Chapter IV describes deployable systems at present. This includes a detailed 
description of the tactical air control system (TACS), and the communications equipment 
which supports the TACS and the tactical air base. Shortfalls and trends highlighted from 
Operation Desert Storm are discussed briefly. 

Chapter V explores the central issues and concepts which must be addressed in 
developing a deployable communications architecture. The emphasis is on understanding 
the interrelationships between the issues to facilitate and stimulate informed decisions 
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regarding the potential shape of future systems. Policy, type of conflict to plan for, 
phasing of equipment arrival, modularity, and distributed processing are key issues. 

Chapter VI provides a summary of the research and recommendations to enhance 
systems integration of deployable communications for the future. 
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II. REVIEW OF STUDIES 



Three studies were reviewed to provide a foundation for the balance of this research. While 
they differed somewhat in their approach and assumptions, they were remarkably consistent in 
their findings and recommendations. 

A. BACKGROUND AND OBJECTIVES 

The studies reviewed were completed between 1985 and 1991, and all were sponsored by the 
Air Force Systems Command (AFSC). 

1. Twenty-First Century Tactical Command and Control (TC 2 -21) 

This study was conducted in 1985 by a group of industry and DoD personnel. Their 
intention was to "...develop an architectural framework for tactical command and control (C 2 ) for 
the early twenty-first century period. ..to guide development of a survivable and sustainable 
tactical C 2 capability...", all against a NATO backdrop. Important assumptions were: 

• Basic USAF mission and doctrine (as stated in Air Force Manual 1-1) would not change 

♦ Basic tactical C 2 functions do not change, although the execution and environment could 

♦ The threat and C 2 structure from the NATO central region provided the baseline of 
consideration to establish maximum requirements of performance 

• The likelihood of worldwide contingency deployments established the need for modularity, 
flexibility, and transportability [Ref. 2:p. I- 1 ] 
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2. Tactical Battle Management (TBM) 

This study, along with the U.S. Air Force Tactical Communications study, was 
conducted by the Air Force Studies Board (AFSB). The TBM study was completed in 1986, but 
the report was not published until 1990 due to changing priorities (as a result of a changing 
world political climate). Scope was limited to conventional tactical air missions for Europe and 
Southwest Asia. Their task was as follows: 

• Examine the operational requirements, independent of the present or likely capability to 
satisfy those needs 

• Survey and project the technology relevant to decision-aiding information technology 

• Match the capabilities to the needs 

• Review the current programs and acquisition process 

• Recommend ways to facilitate the development of effective TBM aids and related 
technology [Ref. 3:p. 1] 

What this amounts to is to find out where the Air Force can apply decision aids to 
assist in TBM, and then determine how to put those tools in place. 

3. U.S. Air Force Tactical Communications 

Completed in 1991, this study was an extension of the earlier TBM study. While the 
TBM study recognized communications as an important element in TBM, the panel was not 
chartered or structured to examine it in detail. This study focused specifically on tactical 
communications support to battle management. By agreement with the sponsor, scope was 
limited to reviewing the USAF's ability to meet the needs of its contingency forces. Their task 
was: 
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♦ Evaluate planned tactical communications capabilities, with particular emphasis on joint- 
service and multi-national interoperability 

• Examine the technological command and control requirements 

• Recommend future concepts for application 

♦ Propose an implementation strategy [Ref. 4:p. 5] 

B. SIGNIFICANT FINDINGS 

1. TC 2 -21 

This study determined that physical dispersal and functional distribution would be key 
to survivability for deployed systems. Figure 1 helps to illustrate this point. From a topology 
standpoint, the greater the separation between elements, the greater the difficultly in locating and 
targeting them. For functional distribution, their idea was to provide redundancy through 
spreading the functions throughout the theater versus concentrating them in focused elements. 
In this way, if one part of the network is disabled, another part can assume its workload. This 
helps eliminate single points of failure. In addition, to take full advantage of technology, manual 
methods of battle management must give way to using automated decision-support capabilities. 
Finally, the need for rapid deployment will drive a "building-block", modular C 2 approach for 
transportability and for allowing incremental levels of capability as required. [Ref. 2:p. ii] 

2. Tactical Battle Management (TBM) 

The TBM study found that current technology would meet the USAF’s needs, but must 
be integrated into the Tactical Air Control System (TACS) to be effective. This is being 
accomplished through programs such as the Modular Tactical Air Control Center (MTACC), the 
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Centralized 




Dedicated support to each function/fadlity 

No replication of functions 

Irredundant central processors 

Many single-point failures 

Readily distinguishable signatures 

Limited modularity 

Limited interoperability 

Low bandwidth, point-to-point communications 

Fully Distributed 




Single common support element 
Theater wide function replication 
Elimination of single point failures 
No distinguishable signatures 
Universal modules 
High Interoperability 
High communication loads 

Semi-Distributed 




Limited classes of support elements 
Dispersed replication of functions 
Elimination of single point failures 
Minimal distinguishable signatures 
Classes of modules 
Moderate communication loads 



Figure 1: Architectural Options [Ref. 2:p. Ill- 19] 






Contingency TACS Automated Planning System (CTAPS), and the Modular Control Element 
(MCE). However, they stated the current development and acquisition system does not get this 
new technology into the field fast enough to meet the Air Force’s needs for TBM. It takes too 
long, and items are frequently outdated by the time they are fielded. It was pointed out that an 
acquisition system which works well for weapon systems does not provide the flexibility needed 
when technologies are rapidly evolving. Finally, the lack of coordinated effort to field essential 
systems has severely impacted the Air Force’s ability to manage tactical air warfare. [Ref. 3:pp. 
3-4] 

3. U.S. Air Force Tactical Communications 

This study highlighted discrepancies in the areas of testing; architecture and engineering. 

They found that communications systems were not stressed during testing in a way that would 

be typical of a warlike environment. This may be at least partially related to the next point of 

there being a lack of knowledge regarding the network loading demands which might be 

experienced under warlike conditions. Without this information, it is difficult to realistically 

stress a network during testing or exercises. Finally, they noted there is a lack of adequate 

systems architecture and systems engineering. According to the report: 

Planning, development, and management of the tactical communications system has been 
and is fragmented and dispersed among several organizations. The Air Force must 
establish a structure for TBM, including the supporting communications, so that the 
developing technologies and the evolving command, control, communications, and 
intelligence capabilities ’fit’ into and contribute to the overall system. [Ref. 4:p. 8] 
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C. RECOMMENDATIONS 



The study recommendations fell into two broad categories: those that related to the 
management of the systems (development, acquisition, and implementation) and those that were 
concerned with the technical means of providing deployed command and control. 

1. Management Issues 

The number one issue from all studies was that a tactical C 2 or battle management 
architect must be designated and given clear responsibility and authority to accomplish the task 
of systems integration. It was noted that the process of design and implementation of systems was 
fragmented among many different offices, and no single agency was responsible for oversight and 
integration of the various efforts [Ref. 2:p. IV- 1, Ref. 3:p. 4, Ref. 4:p. 13]. The TBM study 
along with the TC 2 -21 were critical of the development, acquisition, and testing arenas. TBM 
suggests a better interaction between the users and developers since requirements tend to be 
dynamic and difficult to state in detail. Rapid prototyping and field testing (what they call "build 
a little, test a little") will ultimately be the key to successful development [Ref. 3:p. 4]. TC 2 -21 
pointed out the need for a comprehensive test bed. At the time of its writing, equipment and 
expertise were spread across the country. Little if any networking existed to tie these sites 
together [Ref. 2:p IV-3]. While the National Test Bed (NTB) concept seeks to tie research, 
development and operations sites together through a distributed network, it is unclear if TC 2 -2 1 
was a motivating factor. The USAFTC study further suggested rapid prototyping and field 
testing as part of the evolutionary acquisition approach [Ref. 4:p. 14]. Table 1 summarizes these 
and the following recommendations. 
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2. Technical Issues 



While not a specific recommendation except from the TC 2 -21 study, all reports noted 
that simply using many of the equipments and concepts already available in the private sector 
will provide the ability to field smaller, lighter, and more modular equipment. The USAFTC 
study points out that much of our current equipment is based on 1960’s technology [Ref. 4:p. 9]. 
Advances in electronics and packaging (large scale integration of components) since that time 
have yielded large reductions in size and weight. Finally, the USAFTC states the tactical C 3 
system must remain robust under operational stress and continue to fulfill its essential missions. 
To do this requires knowledge of the missions, expected degradations under stress and enemy 
countermeasures, and loading of the supporting communications network. [Ref. 4:p. 14] 



TABLE 1: SUMMARY OF STUDY RECOMMENDATIONS 



RECOMMENDATIONS 


TC 2 -21 


TBM 


TC 


1. Integrate planning & C 2 architectures 


XX 


XX 


XX 


2. Greater flexibility and user interface in develop- 
ment, acquisition, and testing 


XX 


XX 


XX 


3. Comprehensive testing 


XX 




XX 


4. Develop smaller, lighter, more modular 
equipment 


XX 






5. Robust network under stress 






X X 



D. SUMMARY 

The studies reviewed all made the point of needing to designate a systems architect and 
engineer, and to vest in them the authority to integrate the many aspects of systems design as it 
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is currently performed. Rapid prototyping and field testing, and greater use of commercially 
available items will also speed the transfer of higher technology equipment into the Air Force’s 
deployable communications systems. 
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m. ARCHITECTURES 



This chapter is an overview of the joint and Air Force concepts and architectures 
which are currently guiding the planning and implementation of deployable systems. 

A. C 4 I FOR THE WARRIOR 

Cl for the Warrior (referred to in this section as simply Cl) is a concept paper 
developed by the Joint Staff/J-6 office [Ref. 5]. It provides a high level view of what is 
expected for the warrior and how to transition current systems toward that goal. 

1. Concept and Goal 

The idea behind Cl is to take a top-down approach to integrating technology 
into deployable systems, versus the usual bottom-up approach which can introduce new 
technology quickly but tends to fragment its implementation. The result of the bottom-up 
approach has been the fielding of a great deal of helpful equipment, but much of it 
operates in a stand-alone mode, overloading the warfighter with too much information that 
is uncorrelated between sources. This is unacceptable in a era of increasing emphasis on 
joint operations. The ultimate goal of Cl is to provide "...a fused, real time, ground truth 
picture of [the warrior’s] battle space and the ability to order, respond and coordinate 
horizontally and vertically to the degree necessary to prosecute his mission in that battle 
space.” While many elements must work together to make this happen, the focus in this 
document was only on equipment, not on procedures or doctrine. [Ref. 5:p. 2] 
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2. The Road Map 

While many architectures provide a view of systems on the horizon that will 
be all things to all users, C*I argues that none will provide the needed interoperability 
today. What is needed is an affordable way to make the current systems interoperate to 
give our warfighters the needed edge. With an ideal of being able to pull from the ether 
whatever the warfighter needs, Cl states that standardizing our information exchange will 
enable us to gain the needed interoperability and provide the required "picture" for the 
warrior. 

The single, overriding fact is that interoperable systems must exchange information . 
The foundation needed for interoperability is formed by defining the criteria to 
exchange information. THE STANDARD that is needed is a very straight forward 
definition of the communications protocol and data format required to input and 
extract information from the ’data base in the ether.’ [Ref. 5:pp. 5-6] 

There are a number of advantages to making existing systems interoperable 
through information exchange. The primary reason is that the cost becomes reasonable— 
instead of entirely new systems, only interfaces need to be built to allow existing systems 
to talk. In addition, existing systems are already performing the missions assigned and 
commanders are comfortable with them. What is needed is to enhance their "picture" 
through greater access to a more extensive data base. The point is made that for 
survivability reasons, the "data base in the ether" should not be a single data base, but 
rather a distributed data base. Service architectures would fit under this concept simply 
by meeting the communications protocols and data formats established within the data 
base. [Ref. 5:p. 6] 
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C*I accepts that getting "from here to there" will still be a long, costly 
process, but insists that the goals must be set today and adhered to, or else they will never 
be achieved. The focus will be on concepts such as open systems architecture, pull of 
information (from the data base) versus pushing everything into a commander and letting 
him sort it out, data standards, fusion of intelligence, and tools such as expert systems and 
artificial intelligence to enable construction of the ultimate architecture. [Ref. 5:p. 6] 

3. Moving Toward the Goal 

C*I outlined three areas that will provide the means to realize the goal of 
interoperablity between existing systems and the long range architecture: standards, use 
of resources, and testing. 

a. Standards 

An instrumental factor in defining standards has been the establishment 
of the Defense Information Systems Agency (DISA) (and the Joint Interoperability 
Engineering Organization (JIEO) within DISA) as the single focal point within DoD for 
standards. Getting this concept institutionalized will require all of the CINCs and services 
to use the DISA standards. In addition, the standards must be kept as simple as possible. 
The example of 60 cycle, 115 volt household electricity is used as an analogy. The 
rationale is that keeping the standards simple will keep program costs down. [Ref. 5:p. 
7] 
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b. Use of Existing Resources 

A suggested starting point for an interoperability program would be to 
examine the existing data formats currendy in use, as well as those that industry can 
offer. Studying the current information set may allow correlation of some elements into 
an ultimately smaller and more clearly defined set of data elements. The desire is to keep 
that set as small as possible. Some standards may be able to be used as is, while others 
might need slight or even complete modification. Once the standard is defined, the issue 
of compliance comes up. Compliance will be the responsibility of the system owners, 
and will be verified through testing. [Ref. 5:pp. 7-8] 

c. Testing 

Just as a focal point has been appointed for standards, the Joint 
Interoperability Test Center (JITC) at Fort Huachuca, AZ will be the focal point for 
interoperability testing. The recommendation is to make testing an early priority in 
program life. Eventually, the JITC will have a distributed test capability which will no 
longer require the equipment to be physically located at their premises. Testing will be 
possible through "dial-in" connectivity aimed at making compliance easier and earlier in 
program development. [Ref. 5:p. 8] 

B. JOINT INTEROPERABILITY ENGINEERING ORGANIZATION 
ARCHITECTURES 

The Joint Interoperability Engineering Organization (JIEO) serves as the DoD 
systems engineer for C 4 information systems. In this capacity, they look primarily at 
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interoperability issues between forces supporting the deployed CINCs. They look at 
architectures from three standpoints: long-range objective, CINC interoperability, and 
functional interoperability. [Ref. 6] 

The long-range objective architecture program reviews the current and long-range 
service architectures for potential duplication or interoperability problems. JIEO hosted 
an objective architecture conference in September 1991 where the services briefed their 
conceptual architectures and discussed potential interoperability problems. [Ref. 6] 

The CINC interoperability program reviews the C 4 requirements of the CINC, and 
identifies the elements that will provide C 4 support. These elements could be U.S. forces. 
Federal agencies, or allied/coalition forces. Assessments of C 4 capabilities are made, 
deficiencies identified, solutions recommended, and a detailed implementation plan 
developed. [Ref. 6] 

The functional interoperability program focuses on specific mission areas and is not 
limited in scope to a specific CINC. Again, an assessment of current capabilities is made, 
deficiencies identified, solutions recommended, and an implementation plan developed. 
[Ref. 6] 

Because the products developed are generally classified, no diagrams are included 
in this paper. In addition, many of the documents are under revision in an attempt to 
standardize the information provided. Eventually, these documents will serve as the 
design model for C 4 systems in the joint environment. [Ref. 6] 



17 



C. AIR FORCE COMMUNICATIONS -COMPUTER SYSTEMS 



ARCHITECTURE 

Guidance for the Air Force Communications-Computer Systems (C-CS) Architecture 

is contained in Air Force Pamphlet 700-50, Volume I. It ensures that: 

...validated communications-computer systems requirements are satisfied with 
integrated, affordable solutions. [An architecture’s] purpose is to provide standards, 
systems, protocols, interfaces, and so forth, that must be considered when 
developing, implementing, or modifying Air Force communications-computer 
systems. [Ref. 7:p. 3] 

The intent of the architecture is to keep "today’s innovative solution" from 
becoming tomorrow’s integration nightmare. 

1. Background 

The need for an architecture is driven by the number of systems introduced 
by the various communities (whether functional area, base- or command-level, or Air 
Force wide, or those supporting weapons systems) to meet unique needs. Without a plan, 
all compete for the same limited resources of dollars, cable plant, and space, and with 
little regard toward interoperation with other systems. [Ref. 7:p. 3] 

This situation occurred as an outgrowth of the rapid expansion of technology 
over the last 20 years. As users have become more! literate in the new technologies, they, 
in turn, developed new applications to automate and enhance their operations. Finally, 
as products became available, requirements tended to be written in terms of hardware 
desired, not a capability. Frequently, the technical community was not consulted for ways 
to satisfy the requirement. |Ref. 7:p 3| 
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The 700-series regulations outline a process and family of documents to 
provide the guidance needed to pull all of the elements together. They move from the 
more abstract "vision" outlined in the Planning and Architectural Guidance (a ten year 
planning horizon) to the defined roadmaps that will provide the goal architecture, and 
finally the programming and implementation phases which work in shorter horizons and 
more concrete terms. [Ref. 7:pp. 4-5] 

2. Architectural Development Fundamentals 

There are certain goals, attributes, key concepts, and common processes which 
must span all C-CS efforts. Goals provide the common direction for all levels as systems 
are reviewed for improvement. The goals of the Air Force C-CS architecture, and the 
more specific objectives which support them are shown in Tables 2 and 3. [Ref. 7:p. 8] 

a. Attributes 

An architecture must have influence if it is to affect the long-term C 3 1 
infrastructure. It must also provide a structure to guide the entire life cycle of a program 
and its equipment. The focus must be on wartime requirements, and it must specify 
systems which will meet military requirements even in an era of fiscal contraction. [Ref. 
7:p. 8] 
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TABLE 2: AF C-CS ARCHITECTURAL GOALS [Ref. 7:p. 8] 



GOALS 


1. Ensure mission essential needs for communications-computer systems are supported. 


2. Exploit information as a resource to enhance mission effectiveness and efficiency in both wartime and peacetime . 


3. Ensure mission-essential communication-computer systems are as functionally sunnvable and enduring in stressed 
environments as the forces supported . 


4. Ensure communications-computer systems which process sensitive information provide an adequate level of information 
protection. 


5 . Exploit technology to improve the effectiveness and efficiency of communications-computer systems to meet Air Force 
wartime and peacetime mission requirements. 


TABLE 3: AF C-CS ARCHITECTURAL OBJECTIVES [Ref. 7:p. 8] 


OBJECTIVES 


1 Focus the efforts of communications-computer systems organizations to provide better end-user support . 


2 Enhance communications-computer systems support to end-users to increase mission effectiveness or permit reduction in 
resource requirements. 


3. Provide end users with powerful, flexible, integrated tools to improve responsiveness 


4. Enhance user friendliness of communications-computer systems to reduce training requirements associated with their use. 


5. Provide modern, machine-independent software engineering tools to expedite development of major systems. 


6. Increase portability through "open systems." 



b. Key Concepts 

(1) Understanding the User Requirement. Understanding the user 
requirements (what they call "user information needs") entails information flows, possible 
stress points, and the impact of environmental dynamics. Requirements should be stated 
in terms of mission needs, and not in terms of specific hardware or technologies. [Ref. 
7:p. 8] 
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(2) Interoperability. Since data frequently moves from one system 
to another, systems must be interoperable and compatible with each other at the boundary. 
As more systems are interconnected, the technical architecture should guide system design 
to ensure interoperability at the time of implementation. [Ref. 7:p. 9] 

(3) Open Systems. Open systems allow equipment from many 
different manufacturers to co-exist and interoperate. With renewed emphasis on fully 
competitive contract awards, the C-CS environment will have even greater vendor 
diversity in the future. The layered approach in open systems, which specifies where 
certain technical functions are performed, provides the ground rules any new system must 
meet [Ref. 7:p. 9] 

(4) Distributed Processing. The idea here is to move the information 
as little as possible and keep it as close as possible to the user to meet their needs. The 
pamphlet suggests a robust, shared network of interconnections to facilitate distributed 
processing and standards to define information exchange to minimize data conversions. 
[Ref. 7:p. 9] 

c. Common Processes 

All architectures, regardless of nature or scope, are to follow the same 
basic development process. The steps are as follows: 

1. Describe the baseline architecture, 

2. Identify system requirements, 

3. Identify key factors that affect the architecture, 
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4. Develop a target architecture, 

5. Define an evolutionary path, and 

6. Develop acquisition and implementation strategies to reach the target. [Ref. 7:p.9] 

3. Target Architecture 

The target architecture is shown in Figure 2, and is expected to employ 
concepts stated earlier in a "system of systems which will be robustly interconnected to 
responsively serve all users." The target does not carry a specific time for implementation, 
but most of the features are expected to be in place by the year 2010. [Ref. 7:p. 1 1] The 
target will use the concepts of open systems, multi-level security, and centralized 
communications with distributed processing. Data and software are to be standardized 
to enable the sharing of resources (such as data elements) and reduce duplication of effort. 
[Ref. 7:p. 14] The interplay between the "building blocks" used in the development of 
the architecture is illustrated in Figure 3. 

Each building block is also a "technical architecture" documented in additional 
volumes of AFP 700-50. Because many of the technical architectures/building blocks 
appear in the architecture of interest (deployable systems) it is helpful to briefly explain 
the role of each. 
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Figure 2: Target Architecture (Ref. 7:p. 11] 
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End-User Terminals 









Figure 3: Architectural Building Blocks [Ref, 7:p, 12] 

a. Deployable Communications-Computer Systems 

Deployable systems support a wide range of users through switching 
equipment, transmission media, and access to common-user systems in a deployed 
environment. They provide both intra- and inter-theater connectivity through either local 
or long-haul information transfer. [Ref. 7:p. 11] 

b . Data Management 

Data management sets up the standards which allow different 
applications programs running on different hardware the ability to share data as a 
corporate resource. [Ref. 7:p. 11] 



24 



c. Local Information Transfer 



Local information transfer is the movement of voice, data, video, and 
other services within a base environment. [Ref. 7:p. 11] 

d. Long-Haul Information Transfer 

Long-haul systems provide connectivity to the common-user systems 
managed by DISA, and dedicated command and control systems which reside outside the 
intrabase environment. [Ref. 7:p. 13] 

e. Integrated Systems Control 

Integrated systems control provides the equipment and procedures to 
monitor and troubleshoot network facilities as needed. It serves as a technical control 
point for fault isolation and detection at base level. [Ref. 7:p. 13] 

/. Software 

Future software acquisition and development will be based upon 
commercial products already available, Ada (the DoD standard language), and standard 
databases, tools, and supporting languages. Configuration control will continue to be a 
priority. [Ref. 7:p. 13] 

g. Security 

The objective of security is to protect information from either physical 
or electronic compromise. Technical and procedural measures are employed to 
accomplish this task. [Ref. 7:p. 13] 
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h. Automated Support Systems 



This area includes the dedicated and shared-use computer systems in the 
base environment, with a focus on standard systems. Computers can be those acquired 
from standard requirements contracts or from other sources. An example of the current 
automated support systems is shown in Figure 4. [Ref. 7:p. 13] 

The above concepts all support the overall Air Force C-CS architecture. 
Deployable systems naturally use many of the same building blocks to develop the sub- 
architectures used to support deployed forces. The deployable C-CS architecture is 
discussed next. 
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Figure 4: Automated Support Systems [Ref. 7:p.l3] 
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D. AIR FORCE DEPLOYABLE C CS ARCHITECTURE 



The Air Force Deployable C-CS Architecture (DCSA), as stated in AFP 700-50, 
Volume II, provides the technical structure to realize the target architecture and defines 
an evolutionary path to follow. The document parallels the steps outlined in Section 
III.C.2.C in providing background, the current baseline, the target, and an evolutionary 
strategy. The background is similar to that presented earlier, so will not be repeated. 

1. Current Baseline 

The current baseline of equipment is as depicted in Figure 5. The equipment 
provides the supporting infrastructure for control of combat air forces, airlift assets, and 
the main operating bases (MOB’s). [Ref. 8:p. 10] The present deployable systems are 
covered in greater detail in Chapter IV. 

2. Target Architecture 

The target architecture is designed to overcome shortfalls in the areas of 
voice, data, and transmission systems through an integrated, digital, common-user, 
distributed network. Commercially available technologies and standards, coupled with 
open systems will be used to the maximum extent possible. Components should be the 
same as their fixed-station counterparts, or re-packaged (but not re-designed) to meet 
unique military requirements. [Ref. 8:p. 28] The target architecture is centered around 
an Information Transfer Node (ITN). The ITN serves to route information packets and 
performs network functions. Concepts presented during Chapter II are also included, i.e., 
modularity and distributed systems. Figure 6 shows how an ITN acts as "the primary 



27 



UNIT LEVEL NODAL LEVEL LONG-HAUL LEVEL 




Figure 5: Current Deployable C-CS Architecture [Ref. 7:p. 12] 

building block" for intrabase communications. Each topology will be tailored to the 
specific needs of the attached users. [Ref. 8:p. 37] Groups of users are further 
interconnected across the deployed base through a communications backbone as shown 
in Figure 7. This allows users to transfer information throughout the MOB, and to reach 
long-haul lines not homed off of their ITN. [Ref. 8:p, 38] Finally, Figure 8 depicts many 
MOB’s interconnected. This provides connectivity throughout the theater, and into the 
fixed systems via Defense Communications System (DCS) gateways. [Ref. 8:p. 42] 
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Figure 6: Information Transfer Node [Ref. 8:p. 38] 
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Figure 8: Theater-wide Connectivity [Ref. 8:p. 43] 

3. Evolutionary Path 

The evolutionary path in AFP 700-50 Vol. II is a restatement of previous 
ideas: using an evolutionary approach to integrating commercially available standards, 
technologies, and concepts into the DCSA. The rationale is simple: fiscal constraints 
will not allow the fielding of an entirely new family of equipment. Interfacing existing 
systems to new systems (or among non-interoperable current systems) will be both a 
priority and challenge. [Ref. 8:p. 46] 
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E. SUMMARY 



The consensus from the high level joint guidance through the Air Force technical 
architecture is that deployable systems must be able to support the warfighter. Since 
solutions are needed now, and money is hard to come by, interfaces will play a major role 
in this evolution. The long range objective is to incorporate as much off-the-shelf 
equipment and technology into the deployed environment as possible. This should ensure 
interoperability among users within the theater, and between the fixed environment and 
deployed systems. 



31 



IV. DEPLOYABLE SYSTEMS AT PRESENT 



This chapter provides an overview of the deployable equipment presently in use, 
and introduces some of the challenges presented to those systems during Operation Desert 
Storm. The Tactical Air Control System (TACS) and combat communications provide the 
bulk of what is generally considered deployable or tactical communications. Although 
their missions are different, much of their supporting communications infrastructure is the 
same. 



A. TACTICAL AER CONTROL SYSTEM 

The TACS is, as its name states, a system. A number of components serve to pull 
the entire air picture together. In broad terms, the TACS has two primary missions: 
control and monitor the movements of tactical aircraft, and provide the means for request 
and control of tactical air support (also known as close air or ground support). Figure 9 
shows the overall TACS [Ref. 9:p. 32]. The TACS uses the principle of centralized 
control and decentralized execution in both structure and operation. Its focal point is the 
Tactical Air Control Center (TACC). 

History has shown the absolute necessity for centralized control and decentralized 
execution in tactical air operations. A TACC is the hub of that activity. A TACC 
is the operational facility in which the Air Component Commander (ACC) plans, 
directs, and controls tactical resources. The TACC enables the ACC and his senior 
staff to supervise the activities of assigned or attached forces and to monitor the 
actions of both enemy and friendly forces. [Ref. 10:p. 1] 
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Figure 9: The Tactical Air Control System [Ref. 9:p. 32] 

1. The Tactical Air Control Center 

The functions of the TACC are: force employment, flight management, battle 
management, and systems management. Force employment is the result of the Air 
Tasking Order (ATO)— the translation of the ACC’s guidance and strategy into 
coordinated and detailed execution orders. Flight management monitors the progress of 
assigned missions. Battle management is control of actions taken in direct response to 
those of enemy forces, while systems management ensures the smooth flow of C 2 
information between the various elements of the TACS. [Ref. 10:p. 1] 
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In the joint arena, the TACC is the C 2 system that supports the Air Force 
Component Commander/Commander Air Force Forces (AFCC/COMAFFOR) for airspace 
management. It is dedicated to and operationally responsive to him for airspace control, 
air support coordination and control, and air strike coordination and control. 
Decentralized execution of air missions (the ATO) by subordinate elements of the TACS 
promotes mission effectiveness and enhances responsiveness. [Ref. 1 1 :p. 4-24] 

The combat plans division of the TACC develops the ATO based upon mission 
objectives, availability of forces, and the tactical situation. It tasks units to accomplish 
specific missions in support of the commander’s objectives, and contains enough detail 
to enable the air crews and TACS elements to accomplish those missions. [Ref. 10:p. 2] 
The combat operations division then provides centralized control, monitoring, and 
supervision of the decentralized execution of the ATO. Flexibility is built in to allow 
adjustment to the ATO should the tactical situation dictate. [Ref. 10:p. 4] 

2. Tactical Control, Monitoring, and Coordination 

The TACS uses a tiered approach to assist the TACC in its tasks of 
controlling, monitoring, and coordinating tactical aircraft (and then reporting their 
movements). The subordinate elements to the TACC are the control and reporting centers 
(CRC’s), the control and reporting posts (CRP’s), the forward air control posts (FACP’s), 
the message processing center (MPC), and the airborne warning and control elements. 
[Ref. 9:p. 32] 
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a. Control and Reporting Center 

The CRC is directly subordinate to the TACC and is the primary element 
concerned with decentralized execution of air defense and air space control operations. 
The CRC gets its tasking and receives weapons allocations from the TACC. Sensor or 
radar information comes to it from ground-based sources (such as the CRP’s and FACP’s) 
as well as airborne elements. [Ref. ll:p. 4-24] 

Within its area of responsibility, the CRC directs the region or sector air 
defense and provides aircraft control and monitoring for both offensive and defensive 
missions. It relays, as directed, mission changes to aircraft and coordinates control of 
missions with subordinate TACS elements and other agencies. In addition, it has the 
following responsibilities: 

• Supervise subordinate radar elements 

• Provide threat warning for friendly aircraft 

• Ensure air defense assets of all services are employed in mutually supporting roles 

• Coordinate procedures based upon friendly artillery fire plans 

• Establish the means for air traffic regulation and identification 

• Support air rescue operations [Ref. 12:p. 4] 

b. Control and Reporting Post 

The CRP is subordinate to the CRC and provides radar surveillance and 
aircraft control within an assigned sector. It has similar capabilities to the CRC and can 
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assume CRC functions when directed. One or more CRP’s may be employed depending 
upon area size, terrain, and anticipated level of threat. [Ref. 1 1 :p. 4-24J 

c. Forward Air Control Post 

The FACP is the mobile radar element subordinate to the CRC or CRP. 
It is normally deployed into forward areas to extend radar coverage and to provide control 
of air operations, early warning surveillance, and gap filler service. Because of its 
mobility and compact design, the FACP can be quickly moved to maintain a desirable 
location for a changing tactical situation. During initial or contingency operations, a 
FACP may be the only ground radar available, and would report directly to the TACC. 
[Ref. 12:p. 5] 

d. Message Processing Center 

The MPC supports the TACC, CRC’s, and CRP’s, acting as the interface 
control unit for the TACS. It is the primary element of the TACS that provides for the 
automatic exchange of data with other services and air defense systems. It uses the 
tactical data link (TADIL) to "talk" to other services, and provides the capability to 
translate from one TADIL format to another. This last feature enhances overall service 
interoperability since at least two formats are currently in use between the three military 
departments. [Ref. 1 1 :p. 4-26] 

e. Airborne Warning and Control 

The airborne warning and control system (AWACS) provides an airborne 
radar platform coupled with a C 2 capability. This enables it to perform the function of 
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a CRC or CRP, or to provide enroute C 2 during a tactical deployment. The basic mission 
responsibilities include surveillance, warning, control, and battle management. The 
AW ACS can detect initial hostile air action and provide its radar picture to ground and 
naval units via the TADIL. In addition, the AWACS can monitor surface vessels and 
provide the capability to monitor enemy naval activity, and deny them the advantage of 
conducting covert operations in an area where no surface radar exists. The AWACS can 
also provide information on friendly ground forces through the use of transponders. [Ref. 
12:p. 9] 

The Joint Surveillance Target Attack Radar System (Joint STARS) aircraft 
is not shown as part of the TACS in Figure 9 because it is still under development, but 
it provides a look-down radar to capture the area beyond the forward line of troops 
(FLOT). It has a moving target indicator (MTI) which will detect vehicles in either a 
broad or focused mode, and a synthetic aperture radar which can provide terrain mapping 
or coverage for fixed targets. [Ref. 13:p. 53] 

3. Tactical Air Support and Control 

The elements that assist the TACC in its task of tactical air support and control 
functions are the air support operations center (ASOC), tactical air control parties 
(TACP’s), forward air controllers (FAC’s), the wing operations center (WOC), and the 
airborne battlefield command and control center (ABCCC). [Ref. 9:p. 32] 
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a. Air Support Operations Center 

The ASOC is collocated with the senior Army tactical operations center. 
The ASOC plans, coordinates, and directs immediate tactical air support of ground forces. 
It is subordinate to the TACC, and provides fast reaction for immediate requests for close 
air support, tactical air reconnaissance, and in some situations, tactical airlift. [Ref. 12:p. 
6 ] 

b. Tactical Air Control Parties 

TACP’s are subordinate to the ASOC and are located at each appropriate 
command echelon of the supported ground force, normally battalion through corps. They 
assist the commander through the request and coordination of preplanned and immediate 
tactical air support. [Ref. 12:p. 7] 

c. Forward Air Control 

The FAC’s and Airborne-FAC’s (A-FAC’s) are subordinate to the 
TACP’s and primarily dedicated to direct support of friendly ground forces. They provide 
the detailed coordination and control of close air support that integrates air-delivered 
firepower with friendly ground force fire. Although the FAC’s primary missions are 
controlling attacks, requesting air support, and providing immediate battle damage 
assessment, the A-FAC also performs air surveillance and search and rescue operations 
as needed. [Ref. 12:p. 7] 
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d. Wing Operations Center 

The WOC is subordinate to the TACC and serves as the airwing 
commander’s headquarters. He uses the WOC, with its facilities and staff, to manage and 
control sortie generation by his wing. [Ref. 9:p. 35] 

e. Airborne Command and Control Center 

The ABCCC provides flexibility and control for tactical air missions and 
ensures the ATO is implemented. It normally serves as an extension of the combat 
operations division of the TACC or as an airborne ASOC. The facility is a self-contained 
module carried aboard a specially modified C-130 aircraft (a number of external antennas 
are mounted to accommodate the C 2 radios). The ABCCC can handle only procedural 
control; it cannot perform radar coverage. Radar coverage is provided by the AWACS. 
[Ref. 12:p. 8] 

B. COMBAT COMMUNICATIONS 

Where the TACS has a mission defined in terms of command and control, combat 
communication’s mission is to provide the last "C" in C 3 to facilitate C 2 in the deployed 
environment. In essence, combat communications provides the backbone or infrastructure 
which will link the locations together within a theater, and even across theaters as needed 
[Ref. 14]. Figure 10 shows an overview of a deployed tactical communications network 
including the TACS and combat communications equipment. The elements within the 
TACS were explained in previous sections. 
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Figure 10: Deployable Tactical Communications [Ref. 15:p. 22] 
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Combat communications provides the backbone from the Air Force Component 
Headquarters (AFCH) to the tactical air bases (TAB’s) and into the Defense 
Communications System (DCS). Where the TACS relies upon mission-unique equipment 
(radars and display scopes, for example) for its C 2 mission, it uses much of the same 
equipment as combat communications for its links between sites. These links, as shown 
in Figure 10, are usually provided by the joint tactical communications (TRI-TAC) and 
ground mobile forces satellite communications (GMFSC) equipment 

C. TRI-TAC 

TRI-TAC is the acronym given to the joint tactical communications program and 
the equipment procured under it. The program evolved out of interoperability problems 
experienced by U.S. forces during the Korean and Viet Nam conflicts. In the early 1960’s, 
the U.S. participated in an allied research effort with Australia, Canada, and the United 
Kingdom called Mallard. The intent was to develop an allied communications capability 
based upon evolving digital technologies. In 1969, the Congress mandated that the U.S. 
pull out of the Mallard effort to focus upon U.S. joint-service interoperability. Even 
though Mallard never provided any hardware, it did generate a great deal of technical 
information which would serve as the foundation for TRI-TAC. [Ref. 16:p. 15] 

DoD Directive 5148, May 1971 created the TRI-TAC program and office. This 
program was intended to create a new family of multi-service, interoperable, digital- 
switched equipment that was totally compatible across the family and with existing 
equipment. To do this, common equipment items were divided among the services, who 
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acted as the single development and procurement agent for that item. The major 
objectives of the TRI-TAC program according to the DoD charter were: 

• Achieve the necessary degree of interoperability among tactical communications 
systems and other DoD telecommunications systems 

» Place in the field in a timely manner new tactical communications equipment 
required by the armed forces to perform their mission and which reflected the most 
effective technology 

• Eliminate duplication, where feasible, in the development of service equipment, and 

• Perform the above in the most economical manner 

The TRI-TAC office, specifically the director, was tasked to act as the systems 
architect and principal planner for the TRI-TAC system. [Ref. 16:p. 16] 

The equipment procured can be divided into six general categories: user terminals, 
switching facilities, control element, transmission facilities, multiplexers, and modems. 
By the late 1980’s most of the major equipment had been fielded, and many pieces have 
evolved through internal equipment and software updates. Table 4 provides the description 
and nomenclature of the major pieces of TRI-TAC equipment by category. The multiplex 
and modem equipment is frequently referred to as digital group multiplex (DGM) 
equipment. The AN/TSQ-146 Multiplex Van is not a separate piece of multiplex 
equipment, but rather an assemblage of DGM equipment into a larger van that provides 
a patching and testing capability. 
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TABLE 4: TRI-TAC EQUIPMENT [Adapted from Ref. 16:p. 20] 



TYPE 


DESCRIPTION 


NOMENCLATURE 


User Terminals 


Digital Subscriber Voice Terminal 


KY-68 




Digital Nonsecure Voice Terminal 


TA-954/1042 




Advanced Narrowband Digital 


CV-3591 




Voice Terminal 






Communications Terminal 


AN/UGC-144 




Lightweight Digital Facsimile 


AN/UXC-7 j 


Switching Facilities 


750 Line Nodal Circuit Switch 


AN/TTC-39 




150 Line Unit Level Circuit Switch 


AN/TTC-42 




30 Line Unit Level Circuit Switch 


SB-3865 




50 Line Store and Forward 


AN/TYC-39 




Message Switch 






12 Lice Unit Level Message Switch 


AN/GYC-7 


Control Element 


Communications Nodal Control 


AN/TSQ-111 




Element 




Transmission Facilities 


Troposcatter Radio Set 


AN/TRC-170 




Line-of-Sight Radio Terminal Set 


AN/TRC-173 




Line-of-Sight Radio Repeater 


AN/TRC-174 




Tropo-satellite Support Radio 


RT-1492 




Fiber Optic Interface Unit 


AN/TAC-1 


I Multiplexers 


Multiplex Van 


AN/TSQ-146 




Remote Loop Group Multiplexer 


TD-1233 




Remote Multiplexer Combiner 


TD-1234 




Loop Group Multiplexer 


TD-1235 




Trunk Group Multiplexer 


TD-1236 




Master Group Multiplexer 


TD-1237 








Cable Driver Modems 


Group Modem 


MD-1026 




Low Speed Cable Driver Modem 


MD-1023 




High Speed Cable Driver Modem 


MD-1024 




Remote Loop Group Multiplexer 


MD-1025 




Cable Driver Modem 






Low Speed Pulse Restorer 


TD-1218 




High Speed Pulse Restorer 


TD-1219 
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A word about equipment packaging is in order here. Terminals, multiplexers, and 
modems are usually man-portable devices, ranging in size from a desk telephone to a 
desktop personal computer, and less that 40 pounds. Switching, control, and transmission 
facilities are usually integrated into their own shelters which require the use of 
mobilization equipment and trucks to move them. The Air Force uses the S-280 and S- 
250 shelters for this equipment. The S-280 is about 7’ x 7’ x 14’ and can weigh up to 
10,000 pounds when fully configured. The AN/TTC-39, AN/TTC-42, AN/TYC-39, 
AN/TSQ-111, and one version of the AN/TRC-170 use the S-280 shelter. The S-250 
shelter is sized to fit in the bed of a standard pick-up truck, and can weight up to 6,000 
pounds when fully configured. The trucks that carry this shelter are modified to handle 
the extra weight. A smaller version of the AN/TRC-170 uses the S-250 shelter. 

D. GROUND MOBILE FORCES SATELLITE COMMUNICATIONS 

The ground mobile forces satellite communications (GMFSC) terminals are not 
formally part of the TRI-TAC program, but are complementary since TRI-TAC does not 
include any satellite communications equipment. The Air Force uses two GMFSC 
terminals, the AN/TSC-94A and the AN/TSC-100A. Both use super-high frequency 
(SHF) radios, but the 100A is a larger, multi-carrier frequency version with greater built- 
in redundancy. The lOOA’s are frequently used as "hub" stations, with the 94A’s acting 
as "spokes" and extending the network. Two antennas are available for use, the standard 
8-foot dish or the higher gain 20-foot dish. The GMFSC terminals use the same shelters 
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as does TRI-TAC. The AN/TSC-100A is housed in an S-280 shelter, and the AN/TSC- 



94A uses the S-250. 

Figures 11 to 14 show representative connectivity diagrams for how the TRI-TAC 
and GMFSC equipments are used to support the tactical air base (TAB) and air force 
component headquarters (AFCH) in the near- and far-term. 

E. SHORTFALLS AND TRENDS FROM DESERT STORM 

The conflict in the Middle East affords an opportunity to study how deployable 
systems worked under operational use, as well as a chance to view the larger management 
processes that occur above the theater level. While not exhaustive, four areas are listed 
below. 

1. Phasing of Equipment Arrival 

With an initial emphasis on getting a deterrent presence in theater, the 
communications equipment needed to eventually manage that presence was considered 
a low priority for use of airlift assets. Only after discussions among senior officers to 
alert commanders that they would not be able to control their forces without the 
supporting communications equipment did the priorities move up. But it was still several 
weeks before the larger pieces of equipment arrived. Although the Time Phased Force 
Deployment List (TPFDL) is intended to iron out these details in advance, allocation of 
airlift assets was conducted on an ad hoc basis and was complicated by the non-modular, 
heavy equipment which needed to be transported. [Ref. 17] 



45 




Figure 11: TAB Current (1991) [Ref. 15:p. 231 
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Figure 12: TAB Target (1996-1999) [Ref. 15:p. 25] 
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Figure 13: AFCH Current (1991) |Ref. I5:p. 27) 
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Figure 14: AFCH Target (1996-1999) |Ref. 15:p. 29] 
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RADIOS 




2. Strategic/Tactical Interface 

This area has been, and continues to be, a problem when deployed 
communications equipment attempts to interface with fixed systems such as the DCS 
[Ref. 16:p. 28]. This stems from the different environments each system operates within, 
and the standards and test procedures each accordingly employs. In fact, of the 24 trunks 
between the U.S. and the Middle East, 18 did not work properly until 21 Dec 90— four 
months after intended activation. [Ref. 18] 

3. Satellite Communication Dependence 

The network established for Desert Storm relied greatly upon satellite 
communication (SATCOM) for its success. This medium provided the capability to grow 
and reconfigure under dynamic conditions which the network architects desired. [Ref. 
19:p. 42] SATCOM was the only feasible way to distribute the network over the vast 
theater of operations and provide the connections back into the DCS. Terrestrial 
communications were used to extend the network further from "spoke" sites and served 
to provide the critical redundancy between sites already connected via SATCOM. [Ref. 
19:p. 43] 

4. Paradigm Shift in Operations 

The current command structure for air operations places most of the command 
and control functions physically on the ground. However, during Desert Storm, the roles 
reversed and much of the C 2 of air operations took place in the air. The primary 
platforms involved were the Airborne Warning and Control System (AWACS), the 
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Airborne Command and Control Center (ABCCC), the Joint Surveillance and Targeting 
Attack System (Joint STARS), and Rivet Joint (a signals intelligence aircraft). This is a 
significant departure from the historical command and control role for aircraft as primarily 
sensors. [Ref. 20] This evolution in operations could be shifting the Air Force toward a 
new de facto C 2 architecture which could provide unparalleled capability, but will also 
force designers to deal with growing complexities and associated issues. 

F. SUMMARY 

The Tactical Air Control System and combat communications comprise the majority 
of what the Air Force calls tactical communications. Both systems use the TRI-TAC and 
GMFSC equipment to provide the communications links needed in the deployed 
environment: TACS for the airspace management and control missions, and combat 
communications for theater connectivity. Desert Storm presented challenges to deployable 
systems from both a technical and conceptual standpoint. Not only was the actual 
equipment put to the test, but the entire process of providing command and control has 
been opened up for examination. 
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V. CENTRAL ISSUES AND CONCEPTS 



This chapter is not intended to "solve" the problems currently facing communication 
systems planners, but is an attempt to lay out a selection of variables for consideration 
so as to help "define" the problem. Due to the interdependence of the variables, a 
systems approach was considered appropriate as an analysis method. Every attempt was 
made not to reduce a very complex problem into simple, toy-problem terms, but more 
into chunks that illustrate the interdependence of the elements. 



A. DEFINITION OF C 2 

At the core of any military communications issue should be the reason that 
communication is needed: to facilitate and support command and control (C 2 ) of the 
forces and means of war. JCS Publication 1-02 provides a good starting point for C 2 
from which to build upon. 

1. JCS Pub 1-02 Definition of C 2 

The exercise of authority and direction by a properly designated commander over 
assigned forces in the accomplishment of the mission. Command and control 
functions are performed through an arrangement of personnel, equipment, 
communications, facilities, and procedures employed by a commander in planning, 
directing, coordinating, and controlling forces and operations in the accomplishment 
of the mission. [Ref. 21:p. 77] 

Perfect C 2 implies some level of omnipotence on the part of the commander, 
the ability to have all the desired information available to make a decision at the time of 
the commander’s choosing (what he needs to know when he needs to know it). 
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2. C 2 is Information Centered 



Information, as opposed to raw data, is what allows a commander to make 
decisions that will favorably affect the outcome of war. Paul Stares said in his book 
Command Performance : 

The contribution of command and control to military effectiveness derives from the 
use of its basic commodity-information. With accurate information, uncertainty 
about the surrounding environment can be reduced and decisions affecting the 
readiness, movement, and application of military force can be taken with a clearer 
understanding of the likely costs and benefits. If processed and delivered promptly, 
information can also provide more time for these decisions to be taken and, 
moreover, implemented with successful results. [Ref. 22:p. 19] 

Decisions made without the benefit of information are at best lucky, and at 
worst disastrous. As Stares points out, to be of any value, this information must possess 
at least two qualities: timeliness and accuracy. 

3. Timeliness and Accuracy 

Perfect information should, by implication, possess both timeliness and 
accuracy. In reality, perfect information is not available to the commander. In general, 
accuracy and timeliness are proportional, where highly accurate information can take a 
very long time to prepare and confirm. Under dynamic conditions, this situation would 
not prove helpful. As such, a balance between the two qualities is desirable. Some 
amount of accuracy is traded off to allow the information to get to the commander in time 
to be of value. Determining how "good" is "good enough" and trying to quantify the 
trade off between timeliness and accuracy is beyond the scope of this effort. However, 
assignment of a confidence level to information is one way to provide an indication of 
how sure the source is about the accuracy of the information. 
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There is an economic concept called the "Law of Diminishing Marginal 
Returns" where, as additional resources are used, the incremental increase in output 
declines with higher levels of resource usage. Beyond some point, there is zero or 
negative marginal return for resources used in the production an output. Using the above 
case as an example, it may be possible to attain a 90% confidence for accuracy of 
information within 1 hour, but to improve the confidence an additional 5-9 percentage 
points (to 95-99%) may require an additional 4 hours. Figure 15 illustrates this point in 
graphic form. 




Time 



Figure 15: Confidence in Information Curve 
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The shape of the curve is due to the underlying technologies and processes 
which are used to obtain and confirm the information. A relatively fast sensor may 
indicate the occurrence of an event within a class of events, while different sources may 
be consulted to further narrow the event. All of this confirmation takes time, especially 
where manual intervention is needed. For many applications, the 90% confidence may 
be sufficient to base decisions upon. Policy, sensitivity of decisions, and commander’s 
experience will likely shape the thresholds used in practice. 

What this information allows a commander to do is outperform the opponent 
in real-time under dynamic conditions. Colonel John Boyd illustrated this concept well 
in what is called the "O-O-D-A" loop. 

4. Boyd’s O-O-D-A Loop 

Colonel Boyd, a former USAF pilot and aerial combat theorist, developed this 
model originally for maneuver warfare. It is used here to simplify and illustrate the C 2 
process. According to James Fallows: 

This ’loop’ consists of cycles of observing (O) the enemy’s actions, orienting (O) 
oneself to the unfolding situation, deciding (D) on a counter, and then acting (A). 
The principle is that the side which can complete these cycles more quickly will 
ultimately prevail .... [Ref. 23:p. 19] 

As seen in Figure 16, Boyd’s model does not show the adversary’s O-O-D-A 
loop and the environment that contains both. Dr. Joel Lawson and Prof. Paul Moose 
extended and adapted Boyd’s model to include the adversary’s loop in the overall 
environment, as seen in Figure 17 [Ref. 24:p. 187]. Although different terms are used, 
the functions remain essentially the same. 
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Figure 16: Boyd’s O-O-D-A Loop 
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The balance of this chapter is concerned with the issues and concepts that 
form the basis for designing architectures and systems. Just as the Chief of Staff of the 
Air Force (CSAF) asked his staff: "...how would we set up comms for a Desert Storm 
like operation if we were free to do it the way we want, starting from a clean sheet of 
paper?" we can also build from the ground up. [Ref. 15:p. 31] 

B. POLICY AND ASSUMPTIONS 

We cannot truly start with a blank sheet of paper. The role of policy is to provide 
the planning guidance needed to shape and narrow the feasible alternatives. Viewed in 
terms of operations analysis, policy helps define the objective function and constraints 
used to obtain an optimal solution to a problem. For example, the problem might state: 

Minimize: Cost 

Subject To: Capability > X 

Airlift Requirements < Y 

Personnel Requirements < Z 

Or the problem could be of the form: 

Maximize: Capability 

Subject To: Cost < S 

Airlift Requirements < Y 

Personnel Requirements < Z 

The above illustrates different ways to state the problem. The bottom line is to 
provide an acceptable level of capability for a specified number of dollars. (It should be 
noted that the problem as stated may or may not have a feasible solution). The difficulty 
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arises in trying to write a model which will allow an analytical solution. Many variables 
will of necessity be constrained, i.e., money that can be allotted or current airlift available. 
However, by holding the other values constant and letting the variable of interest run 
unconstrained, the model can return a value that will satisfy the constraints as written. 
While the chosen level of capability may require three times the gross national product 
or more airlift than currendy exists in the world, this can still be used as a planning tool 
for model refinement or to examine the underlying technologies with greater scrutiny. 

Given that previous studies and guidance are leading towards smaller, lighter, more 
modular equipment, and greater interoperability between services and the commercial 
sector, what issues and approaches will shape an integrated transition into the next 
century? Due to the complexity of C 2 systems (organizationally, technically, or the 
human element involved) it may never be possible to enumerate a "best" solution to C 2 
needs. However, through an illustration of the trade-offs involved in differing approaches 
to solving parts of the system, it may be possible to choose a better system than if no 
analysis were performed. Because the initial assumptions or conditions have such a great 
impact upon the direction the system planning will take, it is helpful to review some of 
the current high level guidance. 

1. Joint Publication 1 

If planners are to design systems to perform in a wartime environment, they 
must know what the expected environment will be. However, inconsistencies exist 
between high-level documents, and even within documents. Joint Publication 1 states: 



58 



...the arena of our potential operations is the entire planet, with its surrounding 
aerospace, from the ocean depths to geosynchronous orbit and beyond. We must 
be prepared to defend our national interests in every type of terrain and state of sea 
and air, from jungles, deserts, and tropical seas to polar ice caps. The US Armed 
Forces face the .challenge of mastering multifaceted conditions, unlike nations 
whose military forces can concentrate on a more limited range of environments. 
Indeed, the ability to project and sustain the entire range of military power over vast 
distances is a basic requirement for the US Armed Forces and contributes, day in 
and day out, to the maintenance of stability and deterrence worldwide. [Ref. 25 :p. 
2 ] 



In contrast, the planning emphasis appears to be shifting toward the crisis and 
limited objective warfare (CALOW) environment in the Copernicus architectural 
document, as shown in Figure 18. As will be seen next, the C 2 Functional Analysis and 
Consolidation Review Panel (FACRP) states we should plan for general nuclear war and 



focus attention on the CALOW environment. Any system designed without a clear 
vision of its intended use will likely be compromised in some way. 




Figure 18: Operational Continuum (1990- Beyond) [Ref. 26:p. 2-4) 
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2. FACRP 



With a goal of finding more efficient ways to meet the mission, the FACRP 
reviewed national strategy and policy to assess C 2 operational requirements in support of 
the National Command Authorities (NCA) and Commanders in Chief (CINCs). Their 
purpose was to "...identify cost-effective approaches to satisfying DoD-wide C 2 
requirements, specifically through consolidation of capabilities where such action makes 
operational and economic sense." [Ref. 27 :p. 2] The FACRP went on to list the economic 
and strategy changes, and the C 2 drivers which will shape and impact future architectures. 
These lists are shown in Tables 5 and 6. They also found that the current DoD C 2 
structure would not provide the long-term efficiencies needed, and suggested a new C 2 
structure would have the features below: 

• A consolidated, DoD-wide, global C 2 infrastructure 

• A greater emphasis on joint task forces as the principle tactical operational forces 

• Centrally managed operational support [Ref. 27 :p. 13] 

Even though much of the above information is consistent with the findings 
from the studies reviewed in Chapter II, consistency of policy or planning guidance is still 
a problem. 
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TABLE 5: ENVIRONMENT AND STRATEGY CHANGES [Ref. 27:p. 3] 



Resource Availability 
-US budget constraints 

- Decreasing motivation to fund at Cold War levels 

- Decreasing defense funding advocacy among major allies 

The Soviet Threat 

- Continuing, improving strategic forces 

- Reduced conventional threat to Europe, reduced power projection capability 

- Soviet political uncertainties 

The Increased Regional Threat(s) 

- Political and economic power shifts 

- Insurgency, drugs, terrorism problems 

- Availability, use of advanced weapons, including weapons of mass 
destruction 

Strategy Changes, Force Posture 

- Forward presence, but with reduced forces at fewer overseas bases 

- Backed up by CONUS contingency and reserve forces 

- Planned mobilization, if needed 

Technology Advances 

- High-lethality weapons (e.g., precision guided, chemical, biological) 

- High-capability weapon delivery (missile and airborne) systems 

- Increased use of space 

- New information transmission, processing, support capabilities 
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TABLE 6: C 2 DRIVERS [Ref. 27:p. 7] 



Streamlining and Consolidating 

- Reduce C 2 personnel 

- Consolidate U & S organization elements 

- Eliminate redundant systems where possible 

Risk Management and Acceptance 

- Maintain deterrence, prepare for nuclear war 

- Determine size, nature, and location of forces 

- Determine minimum essential capabilities 

- Standby contingency capabilities 

- Mobilize if necessary 

Strategic Agility 

- Focus on low end of the conflict spectrum 

- Deter, fight regional powers if necessary 

- Support forward-deployed forces 

- Support rapid deployment and redeployment 

- Interact and interoperate with allies 

Force C 2 Interoperability 

- Technical standards and protocols 

- Applications: processing, interpretation 

- Procedures 

- Command response, common understanding 

Force and C 2 Modularity 

- Joint and combined interoperability 

- Relocatable/mobile modular assets 

- Building-block planning tools 

Technology 

- Networking 

- Multilevel security 

- Automation, communications 

- New sensing and reporting systems 
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3. The Next Step 



As stated earlier, because the initial assumptions or conditions have such a 
great impact on the direction system planning takes, they should be clear and consistent. 
This forms the basis of the "givens" from which future trade-off analysis can occur. 

C. PLANNING AND DESIGN CONSIDERATIONS 

Chapter II reviewed three studies which laid out a general direction of smaller, 
lighter, more modular and interoperable equipment as goals for any new deployable TBM 
equipment the USAF might purchase. In addition, 0*1 for the Warrior mentions a goal 
architecture where all systems are connected to an ether. While either concept is not hard 
to visualize as a possibility in its end form, no roadmap exists to join what is currently 
in the inventories with the goal architectures. Many factors may make it difficult, but not 
impossible, to realize these goals. The resolution of the areas explored below are 
considered essential by the author for a cohesive deployable architecture to emerge. 

1. Type of Conflict 

It is not clear from policy exactly what type of warfare the military services 
should realistically prepare for. The conflict spectrum presented from Copernicus implies 
a planning shift, as does the FACRP. Planning should be consistent with the probability 
of occurrence, but must also factor in the "cost" of being unprepared, even for some 
unlikely event. Since the needs of each type of event will be different, the broader the 
range covered (on the spectrum), the greater the compromise in capability for each 
particular application. 
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2. Modularity 

Modularity affords greater flexibility in terms of response and capability sizing 
at the initial stages of a deployment. These modules should be compact and able to be 
configured to meet the needs of a contingency force. Over time, however, if the network 
becomes large, the advantages of the modules could diminish (due to economies of scale) 
but could still be viable if the network is somewhat dynamic. 

How modular to be is also a question, since many functions will still require 
specialized equipment. For example, a telephone switch and a radar are very different 
functions and would likely require different classes of equipment. The family of modules 
as well as what is expected of them must be considered carefully 

3. Statement of Requirements 

Before a communications structure can be developed, requirements must be 
determined. As a result of post-Desert Storm tasking, the USAF (as well as JIEO and 
other organizations) have drafted architectures which now serve as the design model for 
developing the supporting communications structure [Ref. 28]. These architectures are 
helpful in showing which activities are coupled and which are not, but do not show the 
relative capacity that would be required between entities. 
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4. Sizing Requirements 

The capacity requirements of the links that connect the various entities, as well 

as the direction of flow (A to B, B to A, or both) are needed to properly size the network. 

The USAFTC study had this to say about sizing: 

While communications connectivity requirements are understood (i.e., who needs 
to talk to whom) the expected utilization or circuit loading is not well characterized. 
Without this data, the degree to which circuits can be shared in a demand 
assignment or packet switching environment cannot be assessed. [Ref. 4:p. 9] 

To illustrate this, the Air Force Communications Command’s Standard Systems 
Center eventually provided a deployed data network (in support of Desert Storm) capable 
of handling in excess of 200,000 supply and maintenance transactions from 50 sites each 
day-linked back to a host computer at Langley AFB,VA by commercial satellite links at 
over 3 million bits per second (MBPS). But the planning for this network did not get off 
the ground until the first planes were on their way to Saudi Arabia. While the concepts 
had been explored earlier, testing was being accomplished to validate it during the build- 
up of forces. Even after the network was installed and became operational, it continued 
to grow as demands increased. [Ref. 29:p. 58] This situation is likely to be the norm in 
the future, especially as data networks are increasingly used to support the warfighters. 

Understanding what needs to flow between entities will help quantify the size 
of the links needed. Not all information needs to go in every direction. Copernicus uses 
the ideas of "push-pull" to show this. "Push" could be information which is broadcast 
from a central source (such as intelligence information from national assets), while "pull" 
would be queries or requests made for information from a central database. In the "pull" 



65 



mode, the user only draws in the information of immediate interest. [Ref. 26:p. 2-8] Of 
course, actually determining the size of these links will be dependent upon the service 
increment chosen as the basic building block. This is one of the roles that standards play. 

5. Standards 

Standards provide a common reference point for determining required capacity 
of service (how many channels of a given size), and they define the technical parameters 
that equipment must conform to in order to connect to the network. While deployable 
systems use a digital channel based upon a 16 or 32 kilobit per second (KBPS) rate and 
the continuously variable sloped delta (CVSD) voice modulation scheme [Ref. 16:p. 19], 
modem fixed systems use a 64 KBPS rate and the pulse code modulation scheme, 
commonly called a DS-0 channel. The DS-0 channel is part of the larger North American 
Multiplexing Scheme which includes DS-1 and DS-3 (also referred to as T-l and T-3) at 
1.544 and 44.736 MBPS. [Ref. 30:p. 39] Adopting these standards would ease the 
strategic/tactical interface problem highlighted in Chapter IV, and allow the use of modem 
and highly reliable commercial equipment. This would also afford deployed users the 
same level of service they now enjoy in-garrison. In fact, T-l service to the customer 
premises is now common, and T-3 services are appearing rapidly as more tariffs are 
approved [Ref. 31:p. 82]. The down side is an initial investment in new equipment, but 
this has in recent years become relatively inexpensive as commercial standards and 
technology have outpaced military ones. 
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6. Transportation and Phasing of Equipment 



More modular equipment should be easier to move (less air cargo space 
required) at the onset of hostilities since only the required capabilities need to be sent. 
Recall from Chapter II that the initial emphasis for Desert Storm was on getting firepower 
into theater, not necessarily support equipment. Under the current methods, 
communications support for an airwing is provided from organizations outside the wing. 
While this works well for sustainment, it is not responsive to rapid deployment needs or 
contingencies. As such. Tactical Air Command (TAC) is exploring a wing-integral 
communications concept that will deploy with the wing and provide all essential 
communications for the first two weeks. After that, the sustaining equipment and 
personnel would assume the communications functions. [Ref. 29:p. 57] 

While this approach could help alleviate some of the phasing problems that 
arose during Desert Storm, new issues are brought forth. If different people and 
equipment will be responsible for the same support, but at different times, how will the 
handoff be accomplished? If the initial package becomes part of the sustaining force, it 
must be interoperable and compatible with it. Modular design would help ensure the 
follow on forces would be able to add to the capability gracefully. If equipment will be 
"swapped out," the network must be designed in such a way as to ensure an orderly 
transition with little or no outage time. 

7. Dispersal and Distributed Processing 

Dispersal and distributed processing appears as a goal in many architectural 
documents (recall TC 2 -21 and the Air Force C-CS Architecture, for example). This 
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concept spreads equipment and personnel over a greater geographic region to provide a 
high degree of physical protection to both. Embedded in this concept is a very high 
degree of interoperability and conformance to standards. Demands on the network 
infrastructure would increase since each dispersed location must have a connection into 
the network. But it may be possible to reduce or eliminate some of the transportation 
requirements through pre-positioning. In a position paper on tactical C 3 I architectures in 
support of Global Reach, Captain Duncan McKenzie advocates the construction of three 
Global Reach ground entry stations; one on each coast of the United States, and one 
within the footprint of the Indian Ocean satellite [Ref. 32:p. 1]. McKenzie’s premise is 
that these ground stations could handle the "hubbing" function normally assigned to 
theater assets, so that the equipment actually deployed could be in direct support of a 
wing [Ref. 32:p. 7]. 

This is a departure from a traditional hierarchical approach to C 2 , which he 
says works well for ground forces, but not for air forces (as they found out during Desert 
Storm). He attributes this to differences for ground and air forces in their C 2 , intelligence, 
and logistics relationships. [Ref. 32:p. 2] Where ground forces are very hierarchical in 
structure, air forces tend to be more horizontal (at least for the support functions-the C 2 
functions performed by the TACC would still remain hierarchical to retain centralized 
control). Wings deploy to a tactical air base, but get nearly all their support from outside 
the theater. McKenzie points out that only two C 2 circuits originate inside the theater, 
scramble (used to "scramble" alert aircraft toward targets) and CAFMS (computer assisted 
force management system, used to disseminate the ATO). Supply and maintenance 
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functions are remoted from U.S. bases, and intelligence and weather go direct to the wing 
via national sources. [Ref. 32:p. 3] He further asks: "Since the above services require 
little or no intervention by higher echelons within a theater, why not adopt a tactical 
network architecture that simultaneously provides intra-theater C 2 connectivity and direct 
inter- theater connectivity between deployed air forces and their CONUS based sources?" 
[Ref. 32:p. 4] His concept would be to provide the ground stations with connections to 
networks for national information, trunks to other ground stations for inter-theater 
capabilities, and switching facilities for intra-theater needs. A user would reach the 
ground station by satellite, and would be patched to the path their needs dictate. Figure 
19 shows an example layout for a ground station. Note that users can be patched direct 
to another user (a dedicated path), or switched, and can be routed within the theater, or 
into any of the global networks that the ground station can access. 

D. SUMMARY 

There are a great many issues which must be considered if an integrated approach 
to providing deployable communications is to be taken. In some ways, the way in which 
the services are being provided is evolving faster that the present structure can 
accommodate. Some issues focus on the technical aspects of getting equipment to talk 
to and understand each other, while others are more related to planning considerations, 
while others still examine the more fundamental question of how services will be 
provided. All are important if balance and perspective are to be maintained. 
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Figure 19: Example Global Reach Ground Station [Ref. 32:p. 11] 
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VI. CONCLUSIONS AND RECOMMENDATIONS 



A. CONCLUSIONS 

There has been a great deal of effort at many levels to get a handle on the problems 
that face deployable systems. These efforts should be acknowledged for their attempts 
to quantify the problems and develop solutions prior to any of this author’s own 
recommendations. Specifically, the studies reviewed, the after-action reports that followed 
Desert Storm, C*I for the Warrior, and the Functional Analysis Consolidation Review 
Panel (FACRP) all demonstrate that the technical problems are reasonably well 
understood and are solvable. The people behind these efforts are doing their best to take 
a very complex situation, one which crosses many functional boundaries, and meld it into 
a synthesized, cohesive whole. Their work has paved the way for better communications 
support for the warriors in the future. 

Defining the goal and reaching it can be two different things, however. Where it 
appears the technical solutions are within reach, the mechanisms to implement those 
solutions may be cumbersome, or worse yet, non-existent. Integrated problem solving 
should include not only the technical solutions but also the addressing of the means to 
implement those solutions. The recommendations below serve as a starting point for 
getting some of these areas identified, and ultimately solved. 
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B. RECOMMENDATIONS 



I. Assignment of Responsibility and Authority 

Assignment of responsibility and authority has yet to be vested in a single 
focal point. The TBM study called for the creation of a "center of excellence" where 
architectural and technical expertise, as well as information on the TBM activities of other 
services, could be centrally located. [Ref. 3:p. 5] Although a General Officer Steering 
Group (GOSG) and working group have been established for TBM activities, these groups 
meet only periodically to resolve issues of concern and to set broad policy. Their charter 
is included as an Appendix for information purposes. 

It is possible that the GOSG could act as a "board of directors" in guiding the TBM 
activities for the Air Force. However, it is not clear who the members of the 
"communications corporation" really are, what their responsibilities would be, and what 
the relationships between them would be. Following the lead set by DISA, focal points 
should be established for areas under the TBM umbrella. All of these would then report 
back to the TBM architect who would ensure overall harmony of effort. The TBM 
architect should also act as the Air Force focal point for joint activities regarding 
deployable communications. 

Without a center of excellence to guide and shape the efforts of many 
agencies, the Air Force lacks the integration needed to ensure the findings of the studies 
are resolved. Research for this thesis revealed that many entities are developing 
independent architectures outside any broad umbrella structure which might require them 
to fit within [Ref. 33 :p. 1]. On the bright side, actions are being taken by the new 
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architecture and integration division of the Joint Staff and the Office of the Secretary of 
Defense to eliminate duplication of effort and get control of greater than 300 architectures 
[Ref. 34:p. 1]. 

Where to place such a center and how to staff it are tough issues. Since the 
best operational perspective comes from people immersed in the operational environment, 
it may be possible to distribute the "center" geographically to gain expertise, while a core 
group would be responsible for the day-to-day management of affairs. The core group 
would manage the databases and coordination with other services and DoD agencies, and 
the designated, distributed focal points would be consulted and kept apprised through 
messages. For this system to work would require commitment on the part of the 
distributed representatives, and significant dialogue between them and the core group. 
The core group could be co-located with the Technology Integration Center, but to have 
any power, it must have the backing of Headquarters and the major commands 
(MAJCOM’s) to carry out its mission. The expertise is available; it merely needs to be 
assembled and oriented toward the goal. 

2. Follow-up Mechanism 

Possibly at the heart of the above problems is the lack of any institutionalized 
follow-up procedures. The studies did not carry any directive authority to implement their 
recommendations, and the AFSB does not track the status of a study once completed [Ref. 
35]. Nor does the sponsor, Air Force Systems Command (AFSC), have a means yet to 
determine the status of corrective actions taken. Although measures are being 
implemented informally at AFSC, follow-up action will still be sporadic for some time 
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to come. [Ref. 36] One responsibility of the TBM architect should be to gauge progress 
of the current system relative to the goals set forth from sanctioned studies. 

3. Providing the Tools 

a. Policy 

Above all, clear policy is needed to guide the thinking of systems 
architects and engineers. The USAF’s Global Reach, Global Power concept, where we 
desire the ability to respond quickly to any contingency, at any point on the earth, helps 
frame the problems to be solved. But this broad goal will be difficult to reach without 
breaking it into smaller pieces. It is still possible to respond to the challenges with a 
balanced suite of capabilities, where elements of the suite can be individually tailored to 
an appropriate mission. Policy should help determine the level of resources to use in 
realizing each element (based upon the threat and its probability of occurrence). 

b. Models 

Modelling and computer simulations can be valuable tools when 
resources are tight and risks are high. They allow many options to be examined without 
ever having to build a physical system. But to build these models and simulations 
requires good input data if reasonable results are to be expected. The Air Force has very 
little quantitative knowledge on network loading under stress [Ref. 4:p. 8]. Traffic 
analysis records from Desert Storm should prove helpful in developing realistic models 
for wartime communications requirements. However, caution should be exercised since 
the requirements may not be representative or scalable to other situations. An 



74 



understanding of the model will be critical to allow its evolution and growth as 
requirements and future needs dictate. This understanding will hopefully enable 
successful alterations, and provide greater confidence in the results of "what-if" analysis. 
These models would also be able to assist in trade-off analysis to highlight performance 
under various scenarios for the alternatives under study. 

c. Trade-off Analysis 

Within broad guidelines, many different architectures or systems would 
be equally capable of providing suitable service. While this is understood and exploited 
in weapon systems design, it seems to be a relatively new concept to tactical C 2 or TBM. 
A report by the E-Systems Corporation, conducted for the Electronics Systems Division 
of AFSC did attempt to determine the relative merits of a fully centralized versus fully 
distributed TBM approach [Ref. 38:p. 5]. This was an extension of the TC 2 -21 study, 
where the architectures were more fully developed and analyzed. 

d. Artificial Intelligence 

Expert systems and artificial intelligence can be used as database 
management and information decision tools. Recalling the concepts of push and pull of 
information, rule sets can be established to automatically route information to a 
commander. The rule set can be established in advance, and information placed into the 
ether can be tested against the rules. A simple example would be the use of key words, 
similar to the way information is cataloged for libraries. If the conditions specified are 
met, the information is sent to the commander. Otherwise, the information can be stored 



75 



for possible later retrieval. In this way, the commander can pre-filter incoming 
information so that only the information of interest actually arrives at his desk. 

4. Conceptual Clarity 

A recurring theme throughout this research has been a sense of confusion over 
how the different pieces of the puzzle fit together: the relationship between master plans 
and architectures, the relationships between different architectures (technical, functional, 
or those in support of a specific CINC or major command), and the relationships between 
architectures of different services. Logically, there should be a natural nesting of 
architectures from one level to the next. At the risk of over-simplification. Figure 20 
shows how service architectures could be pieced together to form a CINC architecture. 
Further, using the Air Force segment, MAJCOM architectures can be joined to form the 
service architecture. The functional areas are represented as ellipses; they span the entire 
theater, and are represented within each service/M A JCOM architecture as well. 

Sub-architectures can taken down to the desired level of detail, with the caveat 
that connections to other parts of the parent architecture remain clear. In a sense, the sub- 
architectures would be modules that plug into the parent architecture. Sub-architectures 
would also be cascaded to ultimately form the support structure required by the CINC. 

Interoperability should be treated as an issue within an architecture, not as an 
architecture itself. Interoperability between systems is a design goal that can be served 
through clear architectural concepts. Interoperability concerns occur wherever a boundary 
is crossed. This could be between functional areas, services, or commands. Defining the 
standards at the boundaries, and enforcing compliance ensures systems will interoperate. 
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A factor that compounds these conceptual problems is that the word 
"architecture" does not have a universal meaning within the DoD. JCS Pub 1-02 does not 
have an entry for architectures, and dictionaries are not always consistent with each other. 
This has led to many different interpretations of the word and corresponding confusion 
over what should be in an architectural document. [Ref. 38:pp. 2-3] A proposed 
definition is: 

A guide or "blueprint" which outlines the shape and structure of a system, or group 
of systems. It provides a goal to build toward, and shows the boundaries between 
systems and the standards used at the boundaries. 

The essential elements are structure and standards. It should be clear to 
anyone reading an architectural document what would be required for them to interface 
with it. 

5. Systems Training 

Part of the difficulties facing deployable systems may stem from a lack of 
training in "systems" themselves. As stated in Chapter I, systems are more than just the 
sum of their parts, and are characterized by interdependence of elements. Engineers and 
technicians need to understand the individual pieces of equipment, but maybe even more 
important is an understanding of how that piece of equipment contributes to the overall 
network, and the impact to the network if that equipment is dysfunctional. This is 
especially important since, as they progress in their careers, these same people will be 
responsible for designing and implementing new families of equipment. 
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C. THE MISSING LINK 



Integrating deployable communications systems will not be easy; otherwise the 
problem would have been solved by now. But from a systems standpoint, it appears that 
many of the problems are more organizational in nature than technical. Fundamentally, 
this means that the physical system can only be as integrated as the management and 
organizational infrastructure behind it. Where concepts are not well understood or 
executed in organizations, it will be difficult to design these concepts into a physical 
system; the finished product will mirror the strengths and weaknesses of its design. 
While solving the small problems is important, the task still remains to ensure that all the 
solutions are integrated and that the total product produces the desired system 
performance. 

In the goal architectures, the Air Force has asked deployable communications 
systems to perform things which have not yet been solved for the fixed systems— 
compatible data formats, for example. If the organizational and management issues 
behind data formats remain unresolved, the best of equipment will not solve the problem. 
Simply providing a personal computer to Oscar Madison (of the "Odd Couple") will not, 
in itself, make him an organized person. 

If this thesis can leave the reader with a better appreciation for the underlying 
causes of persistent integration problems with deployable communications then its goal 
has been reached. Possibly the single most important concept could be that the way 
systems are fielded is just as critical as the system itself. Study after study can determine 
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where technical problems lie and recommend solutions, but without a coherent mechanism 
to implement to solutions, the best plans will never be fully realized. 

D. SUMMARY 

The technical problems facing deployable communications systems today are fairly 
well characterized and understood. The solutions lie in developing interfaces to allow 
existing equipment to interoperate, while at the same time reaching toward a goal of 
greater use of common standards, open systems, modular equipment, and distributed 
processing. But if the goal of integrated systems is to be reached, the management 
structure which spawns the system must itself become integrated. This author is 
optimistic that both goals can be reached. 
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APPENDIX 



THEATER BATTLE MANAGEMENT 
GENERAL OFFICER STEERING GROUP/WORKING GROUP 

CHARTER 

1. PURPOSE: This Charter defines the membership of the Theater Battle Management 
(TBM) General Officer Steering Group (GOSG) and its subordinate TBM Working Group 
(WG). 

2. SCOPE: Theater Battle Management is broadly defined as that function of AF 
command, control, communications, and intelligence (C 3 I) which supports the rapid 
acquisition and reliable processing, correlation, and dissemination of information required 
for decision making in support of theater operations at all levels from command battle 
management to the mission planning and execution levels. TBM is focused on 
automation of processes, integration of systems, and interoperability of hardware, 
software, and procedures which directly or indirectly affect the speed and efficiency of 
tactical and strategic force execution. The program will orchestrate the fielding of 
selected C 3 I projects through rapid prototyping, evolutionary acquisition, and continuous 
user-developer interaction. The TBM C 3 I goal is to improve our warfighting ability 
through (1) accelerating information flow to the commanders, (2) providing more timely 
information for decisions, (3) providing better decision support, and (4) decreasing the 
tasking-to-execution-to-retasking cycle times. 

3. ORGANIZATION: The GOSG is supported by the TBM WG, which provides a 
forum for: (1) working issues assigned by the GOSG, (2) developing recommendations 
for inclusion of selected efforts within the TBM program, (3) providing activity reports 
to each GOSG meeting, and (4) exchanging information. Neither the GOSG nor the WG 
is intended to supplant existing staff organizations/groups dedicated to resolving TBM 
problems, but rather to provide cross functional guidance and policy. 



a. GOSG membership is comprised of AF customers (TAC/DO, PACAF/DO, 
MAC/XO, AFSOC/CV, AFIC/CV, and AFSPACECOM/DO), requirements developers 
(TAC/DR, MAC/XR, SAC/XR), and suppliers (AFSC/XR, AFCC/CC, ESD/CV, and 
SSC/CC). The chairman is TAC/DR. Other agencies are asked to participate and provide 
expertise in areas of interest to the AF and include representatives from the 
MAJCOM/IN/SC/XP, SAF/AQP, AF/XO/IN/SC, and the suppliers/laboratories such as 
ASD, ESD, Rome and Armstrong Labs, and the TIC. The Secretariat is TAC/DRI. 
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TAC/SCP serves as technical advisor to the Secretariat. Responsibilities for day-to-day 
decision making will be delegated to the TBM WG. 

b. The General Officer Steering Group will: 

(1) Serve as the governing body to set policy for the theater operators on 
procedures, terminology, direction and scope of TBM activities and establish priorities for 
requirements. 

(2) Provide direction, guidance, and support for TBM initiatives and C 3 I 
automation efforts. 

(3) Establish focal points for resolution of problems/issues regarding TBM 
systems’ requirements, funding, development, fielding, and the connectivity between other 
systems. 

(4) Serve as the sponsoring group for the TBM WG. 

(5) Confirm decisions of the TBM WG. 

(6) Meet twice a year (or as required). 

c. Associate (ex officio) membership will be extended to the Army, Navy, and 
Marines. Their participation will be as observers/advisors as required. 

d. The TBM Working Group membership is comprised of customer representatives 
from appropriate TAC, PACAF, USAFE, MAC, SAC, AFSOC, AFIC, and 
AFSPACECOM program offices (both functional and technical), interested air staff 
(SAF/AQP/ACT, AF/XOO/XOR/INX/SCM), suppliers (AFSC, AFCC, AFCSC, ASD, 
AWS, DMA, ESD, SSC, Rome and Armstrong Labs), and joint services (equivalent 
user/developer-level representation). As with the GOSG, TAC/DRI is the Secretariat. 
The group may establish one or more subgroups tailored to address specific 
programs/issues assigned. 



e. The Working Group will: 

(1) Work issues assigned by the GOSG. 

(2) Review, prioritize, and approve TBM needs. 

(3) Monitor TBM programs under development. 
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(4) Oversee TBM laboratory/testbed developments. 

(5) Review advanced TBM technology and command-unique TBM programs 
for AF applicability and recommend candidates for rapid prototyping considerations. 

(6) Define specific TBM interoperability issues and propose solutions. 

(7) Confirm decisions of subordinate working groups. 

(8) Meet as required. 
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LIST OF ACRONYMS 



ABCCC 

ACC 

AF 

A-FAC 

AFCC 

AFCC/COMAFFOR 

AFCH 

AFCSC 

AFIC 

AFSC 

AFSOC 

AFSPACECOM 

ASD 

ASOC 

ATO 

AWACS 

AWS 

C 2 

C 3 

C*I 

CAFMS 

CALOW 

C-CS 

CINC 

CONUS 

CRC 

CRP 

CSAF 

CTAPS 

CVSD 

DCS 

DCSA 

DGM 

DISA 

DMA 

DoD 



Airborne Command and Control Center 
Air Component Commander 
Air Force 

Airborne Forward Air Controller 
Air Force Communications Command 

Air Force Component Commander/Commander Air Force Forces 

Air Force Component Headquarters 

Air Force Cryptologic Security Center 

Air Force Intelligence' Command 

Air Force Systems Command 

Air Force Special Operations Command 

Air Force Space Command 

Aeronautical Systems Division 

Air Support Operations Center 

Air Tasking Order 

Airborne Warning and Control System 
Air Weather Service 

Command and Control 

Command, Control, and Communications 

Command, Control, Communications, Computers and Intelligence 

Computer Assisted Force Management System 

Crisis and Limited Objective Warfare 

Communications-Computer System 

Commander-in-Chief 

Continental United States 

Control and Reporting Center 

Control and Reporting Post 

Chief of Staff of the Air Force 

Contingency TACS Automated Planning System 

Continuously Variable Sloped Delta 

Defense Communications System 

Deployable Communications-Computer Systems Architecture 

Digital Group Multiplexing equipment 

Defense Information Systems Agency 

Defense Mapping Agency 

Department of Defense 



84 



ESD 


Electronic Systems Division 


FACP 

FACRP 

FLOT 


Forward Air Control Post 

Functional Analysis and Consolidation Review Panel 
Forward Line of Troops 


GOSG 

GMFSC 


General Officer Steering Group 

Ground Mobile Forces Satellite Communications 


ITN 


Information Transfer Node 


JCS 

JITC 

Joint STARS 


Joint Chiefs of Staff 

Joint Interoperability Test Center 

Joint Surveillance Targeting Attack Radar System 


KBPS 


Kilobits per second 


MAC 

MAJCOM 

MBPS 

MCE 

MOB 

MPC 

MTACC 

MTI 


Military Airlift Command 
Major Command 
Megabits per second 
Modular Control Element 
Main Operating Base 
Message Processing Center 
Modular Tactical Air Control Center 
Moving Target Indicator 


NCA 

NTB 


National Command Authorities 
National Test Bed 


OSD 


Office of the Secretary of Defense 


PACAF 

PCM 


Pacific Air Forces 
Pulse Code Modulation 


SAC 

SAF 

SATCOM 

SHF 

SSC 


Strategic Air Command 
Secretary of the Air Force 
Satellite Communications 
Super High Frequency 
Standard Systems Center 


TAB 

TAC 

TACC 


Tactical Air Base 
Tactical Air Command 
Tactical Air Control Center 



85 



TACS 

TACP 

TADIL 

TBM 

TC 2 -21 

TIC 

TPFDL 

TRI-TAC 



USAF 

USAFE 

USAFTC 

WOC 



Tactical Air Control System 

Tactical Air Control Party 

Tactical Data Link 

Theater Battle Management 

21st Century Tactical Command and Control 

Technology Integration Center 

Time Phased Force Deployment List 

Joint Tactical Communications 



United States Air Force 

United States Air Forces Europe 

United States Air Force Tactical Communications 

Wing Operations Center 
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